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FOREWORD 


One  of  the  research  goals  of  the  Decision  Sciences  Laboratory  is  the 
development  of  design  principles  for  automated  training  subsystems  which 
could  be  built-into  future  Information  Systems.  Such  subsystems  would 
provide  Information  Systems  with  the  capability  of  training  automatically 
their  own  operators.  To  be  able  to  design  such  a  capability  requires  first 
the  solution  of  many  conceptual  and  experimental  problems.  This  study 
concerns  development  of  a  logic  diagraming  technique  for  use  as  a  training 
aid  in  those  subsystems. 

This  report  is  one  in  a  series  supporting  Task  7  68204,  Automated  Train¬ 
ing  for  Information  Systems,  under  Project  7  682,  Man-Computer  Information 
Processing.  The  research  was  conducted  from  1962  to  1964.  The  Principal 
Investigator  was  Dr.  Thomas  B.  Sheridan  and  the  Contract  Monitor  was 
Dr.  Sylvia  R.  Mayer 
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GRAPHICAL  SYMBOLOGY  AND  LOGIC  DIAGRAMS 


FOR  USE  AS  TRAINING  AIDS 


Abstract 

This  report  describes  the  results  of  a  study  to  develop  a  graphical 
symbology  and  logic  diagraming  technique  for  use  as  a  training  aid. 
This  work  is  addressed  to  the  need  for  a  language  which  describes  the 
logical  relationships  among  task  components  and  the  interactions  be¬ 
tween  man  and  machine  in  advanced  computer-based  information  sys¬ 
tems. 

Symbols  and  a  logic  diagraming  technique  were  developed  and  re¬ 
fined  by  utilization  with  several  different  types  of  tasks.  This  "lan¬ 
guage"  has  been  found  to  be  useful  for  the  following  purposes:  a)  to 
supplement  written  instruction  manuals,  b)  as  an  instructional  tool 
without  text,  and  c)  as  a  performance  aid  when  displayed  directly  on 
an  operational  console.  A  step-by-step  methodology  for  constructing 
logic  flow  diagrams  is  presented,  and  applications  are  discussed. 
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Introduction 


A.  General  Motivations  for  Using  a  Graphical  Notation 

The  general  category  of  graphs  or  diagrams  that  is  the  subject 
of  this  report  is  represented  by  the  linear  graph  of  topology- -a  collec¬ 
tion  of  dots  (nodes)  and  lines  (branches).  Such  a  graph  form  is  a  con¬ 
venient  notation  to  use  when  trying  to  describe  certain  types  of  relation¬ 
ships  among  elements.  Some  typical  examples  are  road  maps,  organi¬ 
zation  charts,  computer  flow  charts,  and  electric  circuit  diagrams. 

Some  of  the  types  of  properties  which  graphs  possess,  in  contrast 
to  tables,  lists,  and  other  forms  of  organization,  are  well  illustrated  by 
the  example  of  a  road  map.  If  we  wished  to  know  the  approximate  time 
to  go  from  A  to  B,  a  point-to-point  table  of  distances  would  allow  us  to 
make  a  rapid  estimate.  But  this  would  not  tell  us  how  to  get  there 
within  the  estimated  time.  Use  of  the  graph  would  tend  to  bog  us  down 
in  a  mire  of  detail  and  decision  as  to  route,  distance,  traffic,  probable 
speed,  etc.  .  On  the  other  hand,  if  we  wished  to  chart  a  route,  the 
graph  (map)  would  be  the  relevant  form.  Again,  to  locate  any  given 
street  or  town,  the  best  method  is  to  use  a  street  or  town  index  and 
map  grid  cross-referencing.  Maps,  graphs,  or  charts  are  useful  for 
showing  the  relationships  among  items.  Single  value  information  is 
best  displayed  in  a  tabular  format. 

The  organization  of  sophisticated  levels  of  information  may  be 
made  possible  by  adopting  some  metrical  properties  in  a  graph.  For 
example,  a  family  tree  which  is  related  to  a  time  scale  in  some  direc- 
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tion  can  display  not  only  genealogical  relationships  but  also  their 
time  relations. 

Although  the  phenomenon  is  not  well  understood,  graphical  forms 
can  serve  as  highly  efficient  clues  to  complex  behavior  patterns.  Many 
electronic  technicians  know  little  of  calculus  or,  perhaps,  algebra,  yet 
they  are  able  (after  some  experience)  to  relate  complex  circuit  perfor¬ 
mance  to  circuit  schematics.  Perhaps  part  of  the  reason  is  to  be  found 
in  the  fact  that  people  generally  have  a  fair  amount  of  practical  contact 
with  graphical  forms  (e.  g. ,  road  maps,  maze  games, and  board  games, 
such  as  Chinese  checkers),  which  may  be  called  upon  in  specific  con¬ 
text.  For  the  electronics  technician,  the  circuit  schematic  is  a  "lan¬ 
guage"  whose  meaning  has  become  evident  through  repeated  associa¬ 
tion.  He  does  not  have  to  have  a  specific  knowledge  of  the  "grammati¬ 
cal  rules"  to  understand  what  it  is  that  the  schematic  describes. 

Another  graph  property  of  interest  is  the  fact  that,  in  the  organ¬ 
izing  of  information,  graph  notation  permits  a  certain  amount  of  modi¬ 
fication  rather  easily,  as  well  as  allowing  abstractions  of  the  informa¬ 
tion  to  be  made  in  the  same  type  of  notation.  There  is  also  the  possi¬ 
bility  of  attaining  considerable  clarity  in  the  presentation  of  certain 
complex  relationships  by  using  a  well-defined  notation  (e.  g. ,  consid¬ 
eration  of  the  typical  task  "cycle"  as  action -question -result -decision). 

When  a  graph  form  is  used  as  a  teaching  aid,  it  often  supplements 
cumbersome  verbal  descriptions,  references  the  items  under  discus¬ 
sion,  and  indicates  logical  relationships. 
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Finally,  there  is  the  possibility  that  such  a  descriptive  form,  when 
applied  to  certain  varieties  of  problem-solving  behavior,  as  indicated 
by  the  Newell -Shaw -Simon  approach  (1),  may  lead  to  additional  insights 
concerning  the  processes  involved. 

More  generally,  the  advantages  of  using  a  graph  to  convey  a  particu¬ 
lar  set  of  information  depend  upon  two  relations:  1)  the  similarity  be¬ 
tween  the  dimensions  of  the  information  to  be  represented  and  a  two- 
dimensional  spatial  graph  (the  dimensions  available  in  a  two  coordinate 
system),  and  2)  the  similarity  between  the  dimensional  graph  and  the 
recipient's  preferred  modes  of  cognitively  manipulating  relationships. 

B.  Requirements  of  a  Graphical  Notation  for  Describing 

Decision  Tasks 

Arnell  (7)  noted  that,  "to  an  engineer,  the  compact  symbols  of 
graphics  represent  the  language  of  communication".  Because  of  the  ad¬ 
vantages  of  such  specialized  languages  the  possibility  of  developing  an 
efficient  symbology  for  man-machine  tasks  should  be  explored.  The 
properties  which  are  desirable  in  a  graphical  notation  which  is  used  to 
describe  console -oriented  decision-making  tasks  may  be  considered  in 
relationship  to  three  areas  of  application.  These  are: 

1.  Some  properties  of  a  good  notation  for  abstract  representation. 

2.  Additional  properties  required  for  use  on  console -oriented  tasks. 

3.  Additional  properties  which  enhance  value  as  an  instructional  aid. 

In  discussing  some  general  properties  of  a  good  man-machine 

notation,  several  ideas  presented  by  Kajori  (2),  in  reference  to  math¬ 
ematical  notation,  are  appropriate.  If  the  symbols  are  to  be  broadly 
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useful,  they  must  be  defined  with  rigor.  One  such  test  is  that  the 
symbols  be  reducible  to  a  set  of  machine  operations,  or  to  another 
statement  of  definition  in  mathematical  terms.  The  symbols  them¬ 
selves  should  be  independent  of  context,  but  should  permit  the  append¬ 
ing  of  context  as  desired. 

It  may  prove  very  useful  to  allow  for  an  individualized  version 
in  conjunction  with  standard  notation,  where  the  individual  part  may 
be  merged  into  standard  form.  This  property  may  encourage  evolu¬ 
tion  of  the  standard  form,  as  well. 

The  above  properties  are  evident  in  computer  flow-charting 
notation  (3).  The  symbols  typically  used  can  be  converted  (even  auto¬ 
matically)  into  machine  instruction  sets.  Clearly,  the  symbols  them¬ 
selves  do  not  depend  on  the  meanings  or  the  values  of  any  quantities 
actually  being  used.  In  addition,  it  is  relatively  easy  to  mix  private 
notation  with  standard  forms,  and  then  merge  the  result. 

When  the  tasks  to  be  described  are  console -related,  there  are 
several  features  of  a  graphical  notation  which  sould  be  exploited. 

One  of  these  features  is  that  the  notation  can  often  be  given  a  spatial 
relation  to  the  actual  console  layout.  In  fact,  console  design  may 
benefit  from  a  description  of  a  proposed  task  in  graphical  terms. 

The  logic  flow  diagram  may  suggest  console  layout  criteria  which  are 
not  apparent  in  any  other  form  of  task  description. 

If  the  graphical  notation  reflects  a  reasonably  sound  model  of 
the  "actual"  processes  involved  in  man-machine  interactions  (at  least 
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certain  types),  then  the  graph  may  help  in  identifying  difficult  and  easy 
parts  of  the  proposed  task.  For  example,  if  the  task  description  shows 
a  sequence  of  many  branch  (decision)  points,  each  dependent  on  memo¬ 
rization  of  preceding  branches,  operator  training  will  be  difficult. 

A  most  promising  aspect  of  using  graphical  symbology  for  con¬ 
sole-oriented  tasks  would  seem  to  be  in  instructional  applications. 

For  example,  a  graph  which  is  very  closely  (if  not  isomorphically) 
related  spatially  to  the  console  layout  could  be  projected  on  the  con¬ 
sole,  controlled  in  its  colors,  intensities,  or  other  qualities,  and  used 
automatically  by  a  teaching  machine.  This  would  be  a  very  powerful 
presentation  device  (see  Section  IV  of  this  report). 

Another  feature  or  property  of  graphs  is  the  ease  of  adopting  a 
convention  to  permit  the  imbedding  of  hierarchical  detail  (see  Section 
III).  For  example,  the  first  graph  may  show  the  entire  task  (logic 
and/or  context)  in  very  concise  form,  and  any  of  several  sections  may 
be  referenced  by  the  end  points  of  a  branch  in  this  graph.  Any  sub¬ 
section  form  will  be  similar  to  that  of  the  superior  graph,  and  the 
structure  may  be  repeated  in  several  levels  (see  Section  III).  The 
potential  training  value  of  such  an  arrangement  (particularly  for 
machine  teaching)  is  enormous  and  may  also  be  valuable  as  a  means  of 
organizing  reference  material.  With  this  arrangement,  an  operator  can 
find  just  the  level  of  detail  he  needs  for  any  desired  section  of  the  task. 

It  is  possible  to  standardize  prose  terminology,  but  the  possibility 
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of  being  able  to  standardize  a  symbolic  graphical  notation,  so  as  to 
permit  a  widely  -transferable  training  in  typical  console -task  patterns, 
seems  even  more  promising.  In  this  respect,  the  use  of  symbols  for 
which  people  have  a  fairly  common  experience  may  be  both  helpful  and 
distracting.  They  may  be  helpful  because  they  seem  "natural",  but  if 
the  person's  experience  is  contrary  to  our  intentions,  they  may  intro¬ 
duce  "noise".  For  example,  some  people  have  difficulty  in  perceiving 
a  convention  which  allows  a  variety  of  different  node  inputs,  but  also 
allows  many  identical  outputs  from  the  same  node.  However,  a  two- 
step  process,  using  two  separate  symbols  for  input  and  output  nodes, 
is  usually  acceptable. 

The  graphical  task  description  is  of  use  in  guiding  the  organiza¬ 
tion  of  an  instruction  manual  for  the  task  and  console.  Because  of  its 
efficiency  in  showing  the  logical  relationships  among  task  components, 
the  graphical  task  description  may  also  serve  as  an  index  for  the  com¬ 
plex  task  instruction  manual.  For  these  applications,  the  notation  must 
clearly  distinguish  the  decisions  which  result  in  diverging  branches  and 
show  where  the  sequences  reconverge. 
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II.  Development  of  Symbols 


A.  Criteria 

A  review  of  the  literature  related  to  analytic  symbology  did  not 
disclose  any  set  of  generally  accepted  symbols  for  describing  man- 
machine  interactions,  but  did  suggest  a  number  of  criteria  for  the  devel¬ 
opment  of  such  a  symbology.  The  criteria  which  governed  the  selections 
used  in  this  study  were  slight  modifications  of  those  described  in  an  ear¬ 
lier  report  (4)  and  included  the  following: 

1.  The  symbols  must  be  easily  learned  and  clearly  distinguish  between 
each  of  the  basic  elements  of  task  cycles  (action,  question,  and  result). 

2.  The  symbols  must  lend  themselves  to  a  presentation  format  in  which 
the  time  or  sequential  continuum  is  intuitively  apparent. 

3.  The  symbology  must  be  capable  of  specifying  unambiguously  and  with¬ 
out  redundancy  the  essential  logical  relationships  of  alternative  actions 
in  man-machine  tasks  characteristic  of  computer-based  systems. 

4.  The  symbols  must  permit  the  appending  of  context  in  a  prominent  loca¬ 
tion,  and  in  such  a  way  as  not  to  distract  from  the  graphical  represen¬ 
tation  of  logical  relationships. 

The  multitude  of  special  purpose  symbologies  described  in  computer 
programing  or  data-processing  manuals,  task  analysis,  or  methods  mea¬ 
surement  texts,  signal  flow  and  circuit  diagraming  manuals,  ASA  and  MIL 
standards  for  graphic  symbols,  etc.  ,  provides  a  rich  background,  and  has 
suggested  a  number  of  the  features  of  the  symbology  developed  in  this  study. 
These  special  purpose  symbologies  have  been  compiled  into  a  recently  pub¬ 
lished  comprehensive  dictionary  of  standard  symbols  (7).  The  majority  of 
basic  symbols  and  variations  of  basic  symbols  described  in  reference  7  do 
not  meet  the  criteria  previously  cited,  probably  because  they  evolved  as  a 
short -hand  notation  rather  than  as  an  analytic  language. 
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B.  Graphical  Information  Carriers 
1.  Lines 

The  primary  properties  of  lines  which  are  readily  perceived 
and  which  can  be  varied  to  increase  information  content  are: 


a.  Continuity  —  —  —  — 


b.  Combinations 

1)  Parallel 

2)  Series 
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c.  Color  (single  or  combination) 

d.  Special  symbols  - 


-vw- 


y  /  /  ) 

The  following  secondary  properties  may  be  varied  for  each  of  the 
above,  but  are  less  easily  perceived: 

a.  Size  (thickness,  length) 

b.  Spacing 

Graphical  flow  charts  used  as  teaching  aids  should  employ  a  min¬ 
imum  number  of  variable  line  properties  which  require  interpretation 
by  the  learner.  Continuous  lines  are  the  easiest  to  produce  and  have 
favorable  association  value.  Broken  lines  or  combination  lines  have 
high  attention  value  if  used  infrequently,  but  will  require  a  key  if  sev¬ 
eral  varieties  are  used  in  the  same  diagram.  Colors  may  be  used  on 
lines  which  are  to  be  coded  from  one  diagram  to  another,  or  to  enhance 
discriminability  of  certain  paths  through  the  diagram.  Such  use  does 
not  require  a  color  key,  since  the  colors  have  no  meaning  and  merely 
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enhance  the  discriminability  of  existing  relationships.  Considerations 
in  selection  of  color  codes  for  flow  diagrams  have  been  discussed  in  a 
previous  report  (5).  Meanings  of  special  symbols  must  be  learned,  or, 
if  infrequently  used,  may  be  described  in  a  key.  Secondary  properties, 
because  of  perceptual  ambiguity,  should  not  be  used  to  increase  the 
information  content  of  graphs  which  are  to  be  used  as  teaching  aids. 

2.  Junctions 

The  angles  formed  at  a  line  juncture,  and  the  orientation  of 

the  junction,  can  be  varied  to  carry  information.  Thus,  a  right  angle 

o 

turn  could  have  a  different  meaning  than  would  a  45  angle.  A  right 
angle  turn  directed  down  could  have  one  meaning  and  an  upright  right 
angle  turn  another.  The  variations  are  many,  limited  only  by  the  dis¬ 
criminability  of  angular  differences  and  by  the  number  of  incident  lines. 

Use  of  a  small  restricted  set  of  juncture  meanings  will  facilitate 
rapid  recognition  and  use  as  a  teaching  aid.  However,  maximum  flex¬ 
ibility  will  be  achieved  only  if  the  juncture  meaning  is  independent  of 
the  number  of  converging  or  diverging  paths. 

3.  Loops  (Shapes  and  Figures) 

The  variety  of  loops  or  figures  which  can  be  devised  to  con¬ 
vey  information  is  virtually  endless.  However,  most  of  those  which 
are  easily  constructed  and  discriminated  are  either  three-sided,  four¬ 
sided,  or  primarily  curved  arcs.  In  addition  to  the  number  of  sides, 
the  shape  may  be  varied.  A  trapezoid  may  have  meaning  different  than 
a  square,  an  obtuse  isoceles  triangle  may  have  meaning  different  than 
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a  right  triangle,  and  a  semicircle  may  convey  a  different  meaning 
than  a  circle.  The  orientation  of  the  figure  may  also  be  varied  to 
change  the  meaning.  For  example,  a  triangle  pointing  to  the  right 
could  be  used  to  carry  different  information  than  a  triangle  pointing 
to  the  left.  Figures  should  be  easily  constructed,  should  be  readily 
discriminable,  even  when  crudely  drawn,  and  should  provide  for  the 
appending  of  context. 

C.  Symbols  for  Man -Machine  Interactions 

The  following  paragraphs  describe  the  graphical  information 
carriers  selected  to  show  the  logical  relations  among  man -machine 
task  elements.  Other  symbols  could  have  served,  but  those  used  in 
this  study  appeared  to  represent  the  best  compromise  among  compet¬ 
ing  criteria.  Since  the  symbology  is  intended  for  application  in  teach¬ 
ing  aids,  simplicity  and  a  minimum  variety  were  the  major  consider¬ 
ations. 

The  basic  task  cycle  usually  begins  with  an  action,  or  series  of 
actions,  followed  by  a  question.  The  symbol  for  an  action  is  a  box, 
for  a  question,  a  double  box: 


action 


question 


The  question  identifies  the  data  requirements  for  evaluation  of  the  re¬ 
sults  (in  a  decision  context).  The  answer  (or  result)  then  specifies 
the  next  action.  Each  question  symbol  is  followed  by  a  decision  sym¬ 
bol  which  designates  the  categories  of  results,  or  answers,  which 
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specify  different  successive  actions.  The  decision  symbol  is  represented 
by  the  interaction  of  a  horizontal  and  vertical  line,  followed  by  the  alter¬ 
native  answer  paths: 

A _ 

decision  as  to  which  path  to  follow 
determined  by  answer  A  or  B 

_ 8 _  — 

The  set  of  alternative  answers  and  successive  actions  must  be  exhaustive. 
Note  that  although  the  action  and  decision  symbols  are  similar  to  those 
appearing  in  computer  flow  charts,  the  question  symbol  is  different  (3). 
Computer  flow  charts  use  the  diamond  symbol  for  a  question.  Branches 
emerge  directly  from  the  diamond  when  there  are  only  2  or  3  alternative 
answers.  The  double  box  was  used  in  the  present  study  because  of  its  ef¬ 
ficiency  for  enclosing  contextual  information  and  clarity  in  appending  an¬ 
swer  source  clues. 


The  complete  task  cycle  runs  from  left  to  right: 

action  - ^  question - ^answer - ^  action  .  .  .  etc. 


The  above  sequence  can  be  described  narratively  as:  action  1  is  per¬ 
formed,  followed  by  question  2.  Depending  upon  the  results  of  past  ac¬ 
tions,  or  the  situation,  the  answer  to  question  2  will  be  A,  B,  or  C. 

The  task  operator  decides  which  answer  is  correct  and  proceeds  along 
path  A,  B,  or  C  taking  action  3,  4,  or  5. 

For  single  man  tasks,  there  is  no  need  for  a  symbol  which  desig¬ 
nates  the  man.  However,  for  multi -man  systems,  there  may  be  a 
need  to  show  the  interactions  among  task  components  performed  by 
different  individuals.  The  symbol  for  a  human  operator  is  a  circle 
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and  is  usually,  but  not  necessarily,  used  at  the  start  of  a  typical  task 


cycle.  For  example,  the  f  blowing: 


shows  man  "a"  performs  action  1  leading  to  question  2.  Depending  on 
whether  the  answer  is  A  or  B,  man  "a"  continues  with  action  3  or  man 
"b"  continues  with  action  4. 

The  lines  connecting  the  symbols  show  the  direction  of  flow.  As 
long  as  the  left  to  right  convention  is  followed,  there  is  no  need  for 
arrows.  In  some  circumstances,  this  convention  may  not  be  practical 
(see  Section  IV)  and  arrows  may  be  necessary. 

Descriptions  of  many  tasks  can  be  written  so  as  to  have  few  or  no 
deviations  from  the  basic  action -question -result  cycles.  However,  in 
some  cases,  the  action  element  may  consist  of  a  series  of  steps  for 
which  it  is  desirable  to  use  symbols  that  discriminate  between  the  or¬ 
dered  and  the  unordered  "and"  relationship.  Similarly,  the  "or" 
branches  are  not  always  contingent  upon  results,  or  answers,  to  past 
questions  and  may  represent  a  choice  based  on  a  whim.  These  logical 
relationships  are  illustrated  as  follows: 

1.  The  "and"  relation 

a.  Sequential  (ordered) 
do  each  in  turn 
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b.  Unordered 


o 


do  all  in  any  order 


□ 

□ 

□ 

□ 


2.  The  "or"  relation 


a. 


b. 


Contingent 


answer  to  question 
specifies  correct  branch 

Whim 

do  any  one,  choice  point 
does  not  follow  a  question 
and  all  branches  are  equally 
acceptable. 


The  preceding  set  of  symbols  has  been  found  to  be  sufficient  to  describe 
a  variety  of  tasks  (see  Section  IV).  However,  in  cases  where  the  task 
description  is  to  be  used  directly  on  the  operational  equipment,  addi¬ 
tional  conventions  are  necessary.  For  example,  in  a  previous  study, 
logic  flow  diagrams  were  drawn  directly  on  an  abstract  model  of  the 
SAGE  console  (4).  These  diagrams  consisted  solely  of  action  and  de¬ 
cision  symbols  keyed  to  a  display  "catalog".  Sequences  of  actions 
were  specified  by  the  display  status,  and,  although  each  such  sequence 
could  be  described  using  the  symbology  previously  discussed,  simul¬ 
taneous  display  of  all  such  sequences  would  have  been  confusing. 
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Since  many  of  the  sequences  of  actions  specified  by  different  displays 
had  common  sub -sequences,  it  was  possible  to  reduce  the  number  of 
paths  by  utilizing  decision  symbols  having  both  multiple  input  and  out¬ 
put  branches.  To  differentiate  between  contingent  and  whim  "or" 
branches,  the  use  of  open  or  closed  arrowheads,  respectively,  was 


adopted. 


a. 


b. 


c. 


Contingent 

do  the  action  specified 
by  the  previous  display 
or  decision  path 


Whim 


do  any  one 


Combination 

do  any  of  the  four  actions 
if  the  decision  point  is 
reached  by  paths  A  or  B. 

If  reached  by  path  C,  do  D, 
if  condition  4  or  6,  do  E  if 
condition  2,  do  F  if  condi¬ 
tion  7 


With  complex  tasks,  the  alternatives  at  a  contingent  decision  point 
may  be  so  numerous  as  to  require  a  lengthy  search.  Then,  perfor¬ 
mance  will  benefit  by  use  of  color  codes  keyed  to  the  display  state. 
Multiple  color  codes  may  follow  the  same  direction  of  flow  symbols 


14 


if  space  permits,  or  codes  may  be  used  only  at  decision  branches. 

Note  that  these  logic  symbols  differ  markedly  from  those  specified  in 
ASA  Y32.  14  or  MIL-STD  806B  for  logic  diagrams.  However,  the  differ¬ 
ences  in  symbols  reflect  the  differences  in  purposes  for  which  they  were 
developed  (analytic  circuit  block  diagrams  versus  teaching  aids). 

Context  should  be  included  within  each  action  and  question  box.  Con¬ 
text  may  also  be  appended  to  the  question  box,  placed  along  the  direction 
of  flow  symbols  after  decision  points,  and  at  the  beginning  and  end  of  each 
diagram.  The  information  placed  within  the  action  symbol  tells  what  action 
or  actions  to  take.  Depending  upon  the  detail  level  of  the  diagram,  the  ac¬ 
tion  may  be  simple  (for  example,  "press  activate  action  button")  or  com¬ 
plex  (for  example,  "reinitiate  action").  Within  the  question  symbol,  insert 
the  question  statement.  Again,  the  level  of  complexity  may  vary  with  the 
detail  level  of  the  diagram  (for  example,  "is  indicator  4  on?",  or  "is  mis¬ 
sion  proceeding  satisfactorily?).  For  instructional  purposes,  the  answer 
source  should  be  appended  below  the  lower  right  hand  corner  of  the  question 
symbol.  Context  appearing  along  the  direction  of  flow  symbols  at  decision 
points  refers  to  the  previous  question  or  display  state.  Examples  of  appended 
context  appear  below.  Yes 


compute 

next 

datum 


have  all 
data  been 
computed? 


^  No 

Data 
check  sheet 


perform 

voltage 

check 


what 

is 

voltage  ? 


less  than  20 


between  20  and  30 


greater  than  30 


meter  G 
on  console 
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HI.  A  Logic  Flow  Diagraming  Technique 


The  following  paragraphs  describe  the  step-by-step  procedures 
for  constructing  logic  flow  diagrams.  The  first  step  consists  of  a 
detailed  task  analysis.  The  task  statement  is  next  interpreted  into  a 
series  of  task  cycle ’symbols  which  are  then  combined  into  diagrama- 
tic  form.  The  diagram  is  then  refined  to  meet  certain  format  require¬ 
ments,  depending  upon  the  ultimate  uses  anticipated.  The  formatting 
procedures  can  be  specified  as  a  step-by-step  iterative  process.  Ex¬ 
amples  of  task  diagrams  are  presented  below,  including  diagrams 
which  describe  the  procedures  for  drawing  task  diagrams. 

A.  Task  Analysis 

A  detailed  task  analysis  represents  an  essential  first  step  in  the 
development  of  any  teaching  (program  (5).  Methods  of  task  analysis 
vary  with  the  end  requirements.  Construction  of  graphic  logic  flow 
diagrams  requires  the  identification  of  task  goals,  sequences  of  actions, 
the  order  in  which  they  are  performed,  and  the  logical  contingencies 
governing  the  selection  of  branching  paths.  Task  analysis  must  there¬ 
fore  tabulate  all  actions,  decisions,  and  goals.  The  logic  flow  diagram 
may  then  be  used  to  show  the  relationships  of  actions  and  decisions  to 
goals. 

The  first  step  in  task  analysis  is  to  identify  the  over -all  objective 
or  goal.  Next,  list  the  actions  which  are  normally  required  under  un¬ 
usual  circumstances  and  identify  actions  which  may  have  to  be  repeated. 
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Specify  the  decision  which  leads  to  use  of  these  alternative  sequences 
or  repetitions.  Insert  these  decisions  along  the  sequential  continuum 
and  then  add  the  alternative  action  branches.  Carry  each  branch 
through  until  the  desired  goal,  or  best  alternative,  is  reached.  For 
each  action,  specify  the  qualitative  and/or  quantitative  criteria  for 
successful  completion.  Is  is  possible  to  fail  to  achieve  any  of  these 
criteria?  If  so,  what  must  be  done  and  what  is  the  information  feed¬ 
back?  In  some  cases,  success  may  be  impossible.  At  what  points 
can  this  be  determined  and  what  actions  are  then  taken.  The  steps 
involved  in  task  analysis  prior  to  logic  diagraming  are  illustrated  in 
the  following  example. 

Consider  the  task  of  telephoning  an  operations  center  for  an  as¬ 
signment.  The  caller  is  presumed  to  know  the  correct  number.  The 
goal  is  to  exchange  information  with  someone  at  the  operations  center. 
The  sequence  of  actions  normally  required  is: 

1.  Pick  up  receiver 

2.  Wait  for  dial  tone 

3.  Dial  number 

4.  Wait  for  answer 

5.  Exchange  information 

Actions  which  may  be  required  under  unusual  circumstances  include: 

1.  A  procedure  to  acquire  a  dial  tone 

2.  Hang  up  and  repeat  procedure  if  no  answer  (also 
recheck  number) 
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3.  Find  another  phone 

4.  Query  answerer  to  ascertain  if  connection  is  correct 

The  decisions  and  criteria  which  lead  to  each  of  these  alternative  ac¬ 
tions  will  now  be  included  along  the  sequential  continuum. 

1.  Pick  up  receiver. 

2.  Decide,  if  there  is  a  dial  tone. 

3a.  If  no  dial  tone,perform  tone  acquisition  procedure. 

4a.  Decide  if  there  is  a  dial  tone. 

5a.  If  no  dial  tone,  find  another  phone  and  return  to  beginning. 

3b.  If  there  is  a  dial  tone,  dial  the  number. 

4.  Wait  for  answer  (up  to  12  rings). 

5.  Decide  if  there  is  an  answer. 

6a.  If  no  answer,  hang  up.  Recheck  number  and  repeat  procedure. 

6b.  If  there  is  an  answer,  query  the  answerer. 

7.  Decide  if  the  right  number  was  reached. 

8a.  If  wrong  number,  hang  up.  Recheck  number  and  repeat. 

8b.  If  correct  number,  exchange  information. 

The  criteria  for  determining  if  there  is  a  dial  tone  and  whether 
the  correct  number  has  been  reached  should  also  be  specified  if  the 
task  is  to  be  taught  to  a  completely  naive  individual.  Further  details 
regarding  the  dial  tone  acquisition  procedure  and  methods  of  dialing 
and  checking  the  number  should  also  be  included. 

The  product  of  the  task  analysis  becomes  cumbersome  with  more 
complex  tasks.  Verbal  descriptions  of  alternative  courses  of  actions 
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become  difficult  to  reference,  and  the  relationships  among  diverging 
or  converging  paths  become  difficult  to  perceive.  Therefore,  use  of 
logic  diagrams  as  reference  sources  during  the  task  analysis  may  be 
advantageous. 

B.  Hierarchical  Levels  and  Layout  Constraints 

A  logic  diagram  which  includes  a  detailed  breakdown  of  all  ele¬ 
ments  of  a  complex  task  may  be  extremely  large.  A  large  and  complex 
diagram  is  undesirable  for  use  as  a  teaching  aid.  The  relationships  of 
individual  actions  and  decisions  to  the  goals  become  lost  in  detail,  and 
more  important  sequences  become  obscured  by  seldom  used  paths.  For 
the  experienced  user,  the  detailed  logic  diagram  may  serve  as  an  aid 
in  tracing  out  procedures  for  unusual  circumstances,  but  the  mass  of 
unnecessary  data  may  impair  rapid  referencing.  Observations  of  both 
naive  and  experienced  subjects'  use  of  detailed  logic  flow  diagrams 
have  confirmed  these  drawbacks  (see  Section  IV)  and  led  to  the  devel¬ 
opment  of  hierarchical  formats  for  logic  flow  diagrams.  Format  re¬ 
quirements  will  differ  between  diagrams  used  as  abstract  representa¬ 
tions  of  the  task  and  those  used  directly  on  the  operational  equipment. 

Logic  flow  diagrams  developed  as  abstract  representations  of  a 
task  should  adhere  to  the  hierarchical  format.  Series  of  minor  task 
cycles  may  be  compressed  into  a  single  task  cycle,  multiple  separate 
actions  into  a  single  inclusive  action,  etc. ,  until  the  over -all  task  can 
be  represented  by  a  maximum  of  7-10  action  and  question  symbols. 
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The  resulting  diagram  shows  only  the  major  decision  points  and  clearly 
shows  the  logical  relationships  among  major  alternative  courses  of  ac¬ 
tion.  The  task  overview  diagram  represents  the  first  level  of  detail. 
Each  of  the  action  and  question  symbols  in  the  level  1  diagram  may  be 
expanded  into  a  7-10  symbol  level  2  diagram,  if  necessary.  Similarly, 
the  action  and  question  symbols  in  level  2  diagrams  may  be  expanded 
in  level  3  diagrams.  The  steps  in  development  of  hierarchical  logic 
flow  diagrams  are  as  follows: 

1.  Organize  the  task  analysis  data  into  chains  of  basic  task 
cycles  (action,  question,  result).  Diverging  chains  originate  at  the 
decision  point  following  each  question.  When  parallel  chains  con¬ 
verge,  they  should  do  so  just  before  an  action  or  question  symbol. 

2.  Eliminate  duplication  of  basic  sequences  through  rearrange¬ 
ment  of  diverging/ converging  branches  or  changing  the  scope  of  any 
individual  unit  (for  example,  an  action  unit  could  include  several  basic 
sequences  which  need  not  be  specified  in  detail  at  this  time).  Major 
decision  points  should  not  be  absorbed  or  obscured  during  this  step; 
the  purpose  of  this  simplication  is  to  eliminate  detail  which  distracts 
attention  from  the  major  decision  points. 

3.  Compress  the  diagram  to  a  maximum  total  of  7-10  action 
and  question  symbols.  The  diagram  will  now  provide  a  superficial 
overview  of  the  entire  task  with  the  most  important  decision  points 
emphasized. 
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4.  Identify  which  symbol -context  units  are  not  self-explanatory 
--follow  steps  1,  2,  and  3  to  diagram  the  sub -sequences  of  each  such 
unit.  Repeat  this  analysis  of  the  units  in  the  second  level  diagrams 
and  form  third  level  diagrams  if  needed.  Continue  to  develop  lower 
order  diagrams  until  all  are  self-explanatory  to  a  person  versed  in 
the  symbology. 

For  displaying  the  diagram  directly  on  operational  equipment,  the 
physical  arrangement  of  the  console  will  govern  format,  and  hierarchi¬ 
cal  structure  will  usually  not  be  possible.  Multiple  action  sequences 
without  intervening  decisions,  and  lack  of  space  for  diagraming  ques¬ 
tions  and  results  will  be  encountered.  A  diagram  developed  for  direct 
console  application  has  been  described  in  a  previous  report  (4).  When 
the  diagram  was  divided  into  successive  frames  for  use  in  programed 
instruction  using  operational  equipment,  console  layout  constraints  were 
much  less  severe  (see  Section  IV).  However,  for  many  existing  consoles 
the  exceptions  to  the  use  of  recommended  symbology  conventions,  even 
with  a  multi -frame  presentation,  would  be  so  frequent  as  to  suggest  the 
need  for  individually  tailored  conventions. 

C.  Examples  of  Task  Diagrams 

In  the  course  of  this  study,  logic  flow  diagrams  were  developed  for 
a  variety  of  tasks.  Some  of  these  diagrams  were  then  used  as  teach¬ 
ing  aids,  others  served  merely  as  examples  for  trying  out  and  re¬ 
fining  the  diagraming  technique.  Several  of  the  diagrams  are 
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reproduced  on  the  following  pages. 

The  task  of  placing  a  telephone  call,  described  earlier,  is  dia¬ 
gramed  in  Figures  1,  2,  and  3.  The  over -all  task  appears  as  a  level  1 
diagram  in  Figure  1.  Two  of  the  symbol -context  units  have  been  ex¬ 
panded  into  level  2  diagrams  in  Figures  2  and  3.  To  facilitate  refer - 
encing,each  action  and  question  symbol  has  been  numbered  in  the  level  1 
diagram  and  the  corresponding  number  carried  over  to  the  level  2  ex¬ 
pansion  of  any  given  unit.  Alphabetic  subscripts  have  been  added  in 
the  level  2  diagram  for  further  referencing  by  level  3  diagrams  (not 
shown). 

The  level  1  diagram  for  performing  the  "numbers  game",  a  que- 
rying-reasoning  exercise,  is  shown  in  Figure  4.  This  game,  described 
in  an  earlier  report  (4),  was  modified  by  providing  the  user  with  book¬ 
keeping  aids.  The  subject  is  seated  at  a  desk  on  which  are  placed  the 
logic  diagrams,  a  stack  of  3  x  5  cards,  a  sheet  of  paper  with  a  list  of 
30  four -digit  numbers  (test  numbers),  and  two  blank  tables  which 
serve  as  bookkeeping  aids  (possible  digits  register  and  scores  regis¬ 
ter).  His  only  prior  instruction  concerns  the  meaning  of  symbols  and 
abbreviations  used  in  the  diagrams.  The  abbreviations  LTN,  PDR, 
and  SR  in  Figure  4  refer  to  the  list  of  test  numbers,  possible  digits 
register,  and  score  register,  respectively. 

It  was  not  possible  to  successfully  teach  the  game  by  use  of  logic 
flow  diagrams  until  a  standard  bookkeeping  procedure  was  introduced. 
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Figure  1.  Overall  Task  Diagram  for  Placing  a  Telephone  Call 
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Figure  3.  Diagram  for  Determining  if  the  Call  Went  Through 
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FIGURE  4.  OVERALL  TASK  DIAGRAM  FOR  NUMBERS  GAME  USING 
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The  essence  of  the  game  is  to  systematically  glean  all  possible  infor¬ 
mation  from  each  successive  query,  and  to  only  use  test  numbers 
which  potentially  will  yield  the  maximum  information.  Consequently, 
the  logic  diagrams  describe  how  to  bookkeep  and  how  to  select  test 
numbers  having  a  maximum  potential  information  content.  The  over¬ 
all  task  diagram  tells  the  user  to  start  by  selecting  and  submitting  a 
test  number.  If  the  user  doesn't  know  how  to  do  this,  he  looks  at  the 
level  2  diagram  for  block  A  (Figure  5).  After  he  has  submitted  the 
appropriate  test  number,  the  question  is  asked  concerning  the  score 
he  received.  He  is  told  to  look  at  the  card  in  order  to  find  the  score. 
Depending  upon  whether  the  score  is  zero  or  1  or  2,  he  takes  action 
C  or  D.  Again,  if  he  does  not  know  how  to  enter  the  PDR  or  the  SR, 
he  consults  the  level  2  diagrams  (Figure  6).  The  user  progresses 
along  until,  through  a  process  of  logical  deduction,  he  is  able  to  iden¬ 
tify  all  four  digits  of  an  "unknown"  number.  An  additional  level  2  dia¬ 
gram  appears  in  Figure  7,  and  two  level  3  diagrams  appear  in  Figure  8. 

The  logic  flow  diagram  in  Figure  9  was  developed  as  one  frame 
of  a  teaching  program  used  in  a  teaching  manual  or  projected  directly 
onto  an  abstract  SAGE  console  representation.  The  task  illustrated  is 
that  of  changing  to  intercept  mode.  When  projected  onto  the  abstract 
console,  the  action  boxes  contained  the  appropriate  controls.  Note 
that  there  are  no  question  or  contingent  "or"  symbols.  The  entire 
sequence  of  actions  was  coded  to  the  display  status  and  contains  only 
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FIGURE  6  LEVEL  2  DIAGRAMS 
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FIGURE  7  LEVEL  2  DIAGRAM 
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Figure  9.  Logic  Flow  Diagram  for  Projection  Onto  Console. 


ordered  "and",  unordered  "and",  and  whim  "or"  symbols.  The  se¬ 
quences  of  display  changes  for  successful  and  unsuccessful  missions 
were  represented  diagramatically  and  used  by  the  console  operator  as 
a  reference  source  (a  more  detailed  description  of  the  diagrams  used 
in  this  application  appears  in  reference  6). 

The  procedures  for  developing  logic  flow  diagrams  are  sum¬ 
marized  by  the  diagram  in  Figure  10.  Note  the  importance  of  being 
able  to  specify  the  questions  and  answers  which  govern  the  selection 
of  alternative  actions.  The  detailed  procedures  for  developing  logic 
flow  diagrams  are  not  in  themselves  difficult  to  express  in  a  narrative 
fashion.  Therefore,  lower  level  diagrams  are  not  warranted. 
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Figure  10.  Procedures  for  developing  a  task  logic  flow  diagram. 


IV.  Use  of  Logic  Flow  Diagrams  as  Teaching  Aids 


A.  Pre -Instruction  Requirements 

Individuals  exposed  to  the  logic  flow  diagraming  symbology 
for  the  first  time  may  experience  considerable  difficulty  in  guessing 
the  correct  meanings.  However,  after  a  simple  explanation  or  instruc¬ 
tional  course  concerning  the  symbols,  most  persons  can  follow  the  dia¬ 
grams  without  requiring  further  assistance.  The  extent  of  pre -instruc¬ 
tion  required  has  not  been  systematically  studied.  The  most  extensive 
pre  -instruction  provided  in  any  of  the  experiments  conducted  to  date 
consisted  of  having  the  subject  read  a  four -page  manual.  The  manual 
contained  a  description  of  the  symbology  and  an  example  in  which  the 
task  of  placing  a  telephone  call  was  diagramed.  Reading  time  averaged 
less  than  5  minutes,  after  which  all  six  subjects  successfully  performed 
an  unfamiliar  task  (the  numbers  game)  guided  by  only  a  set  of  logic  flow 
diagrams  (6). 

No  fallow -up  experiments  have  been  conducted  to  determine  whether 
the  effectiveness  of  logic  flow  diagrams  as  a  teaching  aid  increases 
when  the  students  have  had  repeated  past  exposures  to  the  symbology. 
However,  experience  with  other  graphical  notation  systems  suggest 
that  performance  measures,  such  as  speed  of  comprehension,  continue 
to  improve  over  periods  of  practice  much  longer  than  the  5  minutes  used 
in  the  previously  described  experiment.  Therefore,  adoption  of  a 
standard  symbology  for  man-machine  interactions  may  tend  to  increase 
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its  efficiency  as  a  teaching  aid  beyond  that  demonstrated  to  date. 

B.  Types  of  Tasks  Which  May  Be  Diagramed 

The  variety  and  complexity  of  tasks  which  may  be  described  in 
logic  flow  diagrams  is  limited  only  by  the  skill  of  the  task  analyst. 
However,  the  value  of  constructing  logic  flow  diagrams  for  use  as 
teaching  aids  will  depend  on  the  nature  of  the  task.  Manipulative 
skills,  for  example,  cannot  be  learned  from  logic  flow  diagrams,  and 
extremely  simple  tasks  will  not  warrant  the  development  of  logic  flow 
diagrams.  For  example,  the  procedures  for  manual  shutdown  of  a 
nuclear  reactor  could  be  beneficially  displayed  in  logic  flow  diagram 
form,  but  a  diagram  is  not  needed  to  instruct  the  operator  how  to  turn 
out  the  overhead  lights  before  leaving. 

Some  tasks  may  not  appear  amenable  to  diagramatic  represen¬ 
tation,  but  portions  of  the  task,  or  sub -routines,  may  be  beneficially 
diagramed.  For  example,  a  description  of  automobile  driving  would 
be  difficult.  However,  a  logic  flow  diagram  for  dealing  with  a  car  that 
refuses  to  start  would  be  a  very  useful  tool.  Specific  items  should  be 
checked  in  an  ordered  sequence,  and  alternative  courses  of  action  fol¬ 
lowed  according  to  the  results. 

Logic  flow  diagrams  may  have  their  greatest  potential  as  teach¬ 
ing  or  user  aids  when  applied  to  the  operation  of  computer-based  infor¬ 
mation  systems.  One  of  the  authors  of  this  report  has  developed  a 
logic  flow  diagram  for  instructional  and  reference  use  for  the  LOGIN 
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procedure  on  a  time -shared  teletype  console.  The  relationships  among 
the  actions  and  results  are  cumbersome  to  express  in  a  narrative 
fashion,  but  are  easily  perceived  in  diagramatic  form.  Also,  many 
computer -oriented  individuals  are  adept  at  constructing  and  reading 
program  flow  charts  and  should  have  no  difficulty  in  applying  this  new 
symbology. 

In  the  teaching  of  computer  programing,  difficulty  is  often  encoun¬ 
tered  with  the  iterative  loop  concept.  For  this  reason,  the  diagrams 
which  were  drawn  in  the  course  of  this  study  have  avoided  the  use  of 
an  iterative  loop  notation.  In  cases  where  a  loop  was  needed,  the  first 
step  was  diagramed  and  an  action  symbol  used  to  specify  repetition  of 

the  previous  equence  of  steps.  For  example,  blocks  C  and  E  in  Fig- 

5  5 

ure  6  could  have  been  deleted  by  a  loop  notation  which  guides  the  user 
back  to  C  and  E  ,  and  which  increments  the  digit  or  column  under  con- 

Ci  1 

sideration.  It  has  not  been  established  whether  additional  symbols  are 
needed  to  specify  initial  conditions,  indexed  variables,  terminating  con¬ 
ditions,  and  contingent  transfer  back  to  the  start  of  the  loop. 

C.  Other  Applications 

In  addition  to  describing  the  relationships  among  task  components, 
logic  flow  diagraming  techniques  may  be  a  useful  aid  in  the  organization 
of  instruction  manuals.  The  instruction  manuals  for  two  dissimilar 
tasks  have  been  written  and  organized  to  correspond  to  logic  flow  dia¬ 
grams  developed  for  the  tasks  (6).  In  one  case,  logic  flow  diagrams 
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developed  for  portions  of  the  task  were  included  in  the  text  material. 
Although  other  techniques  for  organizing  training  manuals  might  serve 
equally  well,  or  the  same  organization  might  have  evolved  without  the 
necessity  of  logic  diagraming,  this  method  is  suggested  because  of  its 
intuitive  appeal,  ease  of  application,  and  ease  of  standardization.  For 
speed  of  referencing,  a  table  of  contents  can  also  be  constructed  in  dia- 
gramatic  format. 

Sequential  action  symbols  have  been  used  on  equipment  control 
panels  for  many  years,  but  no  formal  symbology  had  evolved  to  show 
the  logical  relationships  among  task  elements.  Use  of  logic  flow  dia¬ 
grams  displayed  directly  on  control  panels  has  been  shown  to  be  feasi¬ 
ble.  Control  panel  layout  is  seldom  designed  to  permit  left  to  right  or 
top  to  bottom  flow  conventions.  However,  as  manipulative  demands 
for  the  operation  of  controls  decrease  and  instructional  requirements 
increase,  it  may  be  desirable  to  organize  the  physical  layout  of  con¬ 
soles  according  to  new  criteria. 
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V. 


Conclusions  and  Recommendations 


A  logic  flow  diagraming  symbology  has  been  developed  and  has 
been  demonstrated  to  be  useful  as  a  teaching  aid  for  a  variety  of  tasks. 
A  technique  for  constructing  logic  flow  diagrams  for  virtually  any  type 
of  task  has  been  described.  However,  the  most  important  area  of  ap¬ 
plication  is  for  the  description  of  decision-type  tasks.  In  addition  to 
use  as  a  teaching  aid,  logic  flow  diagrams  may  suggest  criteria  for  the 
layout  of  control  panels  and  for  the  organization  of  instruction  manuals. 

It  is  recommended  that  logic  flow  diagrams  be  constructed  which 
describe  the  operation  of  an  advanced  Air  Force  Information  System. 
These  diagrams  should  then  be  integrated  into  the  existing  or  planned 
operator  training  program  on  an  experimental  basis.  The  diagrams 
should  also  be  examined  in  relation  to  the  console  layout,  and  potential 
cost/benefit  trade-offs  of  redesign  assessed. 
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